home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-mhsds-822dir-03.txt
< prev
next >
Wrap
Text File
|
1993-07-08
|
10KB
|
362 lines
Network Working S.E. Kille
Group ISODE Consortium
INTERNET-DRAFT July 1993
Expires: January 1994
Use of the Directory to support routing for RFC 822 and related
protocols
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months.
Internet Drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet Drafts
as reference material or to cite them other than as a ``working
draft'' or ``work in progress.''
Please check the I-D abstract listing contained in each Internet Draft
directory to learn the current status of this or any other Internet
Draft.
Abstract
This document defines a mechanism to route RFC 822 using the OSI
Directory. The basic mechanisms are being developed for routing X.400
[3]. These offer a number of benefits relative to the current
mechanisms available for RFC 822 routing. The prime goal of this
specification is to provide integrated routing management for sites
using both RFC 822 and X.400 [1, 4].
This draft document will be submitted to the RFC editor as a protocol
standard. Distribution of this memo is unlimited. Please send
comments to the author or to the discussion group
<mhs-ds@mercury.udev.cdc.com>.
INTERNET--DRAFT RFC 822 routing using X.500 July 1993
1 Specification
The domain hierarchy of an RFC 822 mailbox information are represented
in the directory according to RFC 1279 [2]. This will allow domains
and mailboxes to be verified. This information is used primarily for
address checking and for mapping onto specific RFC 822 protocols.
Protocol modules should utilise native RFC 822 directory and routing
services (e.g., SMTP should use DNS) [8, 5, 6].
The structure of the MHS Use of Directory to Support Routing [3] is
designed so that RFF 822 mailboxes and X.400 mailboxes can be the same
entries with the same relative distinguished names. This will enable
the level above the mailboxes to be linked with an alias. This will
significantly reduce the complexity for a dual X.400/RFC 822 site.
Authoritative answers can be given for parts of the DNS tree where
registration is complete (i.e., all of the children are present, and
so any other purported child will be illegal). This is achieved by
the subtreeInformation attribute as defined in [3] and referenced in
Figure 1.
Once validity of a domain is determined, routing must be done. This
information is not relevant to a site without RFC 822 support, as it
will not be doing domain based routing. The basic node contains
information specific for SMTP based routing is given in RFC 1279 (MX
and A record information).
The attribute x400Domain indicates that some or all of the subtree
under the domain specified uses X.400. If the value is ``x400-only'',
the domain exists purely to represent X.400 addresses in the RFC 822
world, and X.400 routing should be used if possible. If the value is
``x400-and-822'', then protocol choice should reflect local policy
(e.g., to prefer X.400 or to avoid protocol conversion). Protocol
conversion should be avoided.
For sites with SMTP on the Internet, any valid domain may be routed
through SMTP. DNS Information is also available in the tree, to
facilitate route calculation (RFC 1279 and RFC 974 [7]).
For sites with JNT Mail support, the jNTMailSupport attribute
indicates that the domain supports JNT Mail, and gives sufficient
information to make a routing decision. This mechanism is included to
show how the directory can handle RFC 822 mail routing beyond SMTP.
Local addresses are handled in the same way as for X.400, as described
in [3]. The approach is designed to be convenient for either
environment. Where a site supports both, the appropriate parts of the
O/R Address and Domain namespaces should be linked by aliases. The
Kille Expires: January 1994 Page 1
INTERNET--DRAFT RFC 822 routing using X.500 July 1993
_______________________________________________________________________
822Node OBJECT-CLASS
SUBCLASS OF domain
MAY CONTAIN {
subtreeInformation,
x400Domain,
badAddressSearchPoint,
badAddressSearchAttributes}
::= oc-822-node
x400Domain ATTRIBUTE 10
WITH ATTRIBUTE-SYNTAX X400DomainType
::= at-x400-domain
X400DomainType ::= ENUMERATED {
x400-only(1),
x400-and-822(2) }
jNTMailNode OBJECT-CLASS
SUBCLASS OF 822Node 20
MAY CONTAIN {
jntMailSupport }
::= oc-jnt-mail-node
jNTMailSupport ATTRIBUTE
WITH ATTRIBUTE-SYNTAX JNTMailSupport
::= at-jnt-mail-support
JNTMailSupport ::= SEQUENCE {
supported-nets BITSTRING { 30
janet(1),
pss(2),
ipss(3),
ixi(4) }
application-relay DistinguishedName }
_________________Figure_1:__RFC_822_Node_Information___________________
Kille Expires: January 1994 Page 2
INTERNET--DRAFT RFC 822 routing using X.500 July 1993
object pointed to should be of object class domain-component and
or-address component.
An MTA identifies a local address by finding its own name (Application
Process) as one of the MTAs that supports the UA in question. This is
the same as for O/R Address checking.
One problem with bootstrapping this approach is that there is a need
to load the DNS namespace information into the DIT. This can only be
done gradually. Fortunately, there is no requirement for all of the
domain name information to be in the DIT. The minimum needed is:
o Users local to the MTA, and the tree leading down to that
o All of the top level domains
o Information needed to verify or deny partially qualified domains.
The DNS could be used as an alternative checking mechanism at this
point. The disadvantages of doing this are:
o No mailbox (UA) checking
o No support for multiple RFC 822 protocols
Multiple Domain Routing Trees can be established analogously to O/R
Address routing trees. This is important for:
o Sites with RFC 822 support, but not JNT Mail or SMTP.
o Sites which gateway RFC 822 to other protocols (e.g., UUCP).
2 Content Type Capabilities
Attributes are defined to register MIME content types. This will
facilitiate routing and conversion services.
*** tbs
Kille Expires: January 1994 Page 3
INTERNET--DRAFT RFC 822 routing using X.500 July 1993
3 Example
*** tbs
References
[1] D.H. Crocker. Standard of the format of ARPA internet text
messages. Request for Comments 822, University of Delaware,
August 1982.
[2] S.E. Kille. X.500 and domains. Request for Comments RFC 1279,
Department of Computer Science, University College London,
November 1991.
[3] S.E. Kille. MHS use of the directory to support MHS routing, July
1993. Internet Draft.
[4] CCITT recommendations X.400 / ISO 10021, April 1988. CCITT
SG 5/VII / ISO/IEC JTC1, Message Handling: System and Service
Overview.
[5] P. Mockapetris. Domain names - concepts and facilities. Request
for Comments RFC 1034, USC/Information Sciences Institute,
November 1987.
[6] P. Mockapetris. Domain names - implementation and specification.
Request for Comments RFC 1035, USC/Information Sciences
Institute, November 1987.
[7] C. Partridge. Mail routing and the domain system. Request for
Comments 974, DDN Network Information Center, SRI International,
February 1986.
[8] J.B. Postel. Simple Mail Transfer Protocol. Request for Comments
821, DDN Network Information Center, SRI International, August
1982.
4 Security Considerations
Security considerations are not discussed in this INTERNET--DRAFT .
Kille Expires: January 1994 Page 4
INTERNET--DRAFT RFC 822 routing using X.500 July 1993
5 Author's Address
Steve Kille
ISODE Consortium
PO Box 505
London
SW11 1DX
England
Phone: +44-71-223-4062
EMail: S.Kille@ISODE.COM
DN: CN=Steve Kille,
O=ISODE Consortium, C=GB
UFN: S. Kille, ISODE Consortium, GB
Kille Expires: January 1994 Page 5
INTERNET--DRAFT RFC 822 routing using X.500 July 1993
A Object Identifier Assignment
_______________________________________________________________________
mhs-ds OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) private(4)
enterprises(1) isode-consortium (453) mhs-ds (7)}
rfc-822 OBJECT IDENTIFIER ::= {mhs-ds 6}
oc OBJECT IDENTIFIER ::= {rfc-822 1}
at OBJECT IDENTIFIER ::= {rfc-822 2}
10
oc-822-node OBJECT IDENTIFIER ::= {oc 1}
oc-jnt-mail-node OBJECT IDENTIFIER ::= {oc 2}
at-x400-domain OBJECT IDENTIFIER ::= {at 1}
at-jnt-mail-support OBJECT IDENTIFIER ::= {at 2}
_______________Figure_2:__Object_Identifier_Assignment_________________
Kille Expires: January 1994 Page 6